There is a Type called “Stream” with a TypeKind of “Stream”. At the time of writing this is the only use of the TypeKind “Stream” and so on this page “Stream” is used to refer to either of these entities interchangeably.

A “Stream” is a sequence of bytes – typically a very large number of bytes.

“Stream” for essence

For example, essence data is stored in a “Stream”. Elements of Type “Stream” are part of the high-level logical model of both AAF and MXF files. In AAF the logical model is fully represented in the AAF file (even with MetaDictionaries etc) – AAF has ‘hidden’ mechanisms for storing Streams efficiently in the file – they are stored physically separately to the Header Metadata. In MXF the full logical model is NOT stored; for example, no MetaDictionaries are stored (as standard) in an MXF file. Also, no Elements in the MXF Header Metadata can be of Type “Stream”. Instead, MXF provides (and explictly exposes) a system of Containers to hold Streams which are identified with “Stream IDs”. Header Metadata identifies Streams using Elements that contain “Stream IDs” (which are integers).

AAF defines the EssenceData Class as having three properties (ignoring inherited properties):

  • “LinkedPackageID” (mandatory)
  • “SampleIndex” (optional) – Type: “Stream”
  • “EssenceStream” (mandatory) – Type: “Stream”

In MXF the relevant Metadata Set is “Essence Container Data” which has three properties (ignoring inherited properties):

  • “Linked Package UID” (mandatory)
  • “IndexSID” (optional) – Type: “UInt32”
  • “BodySID” (mandatory) – Type: “UInt32”

The “EssenceData” Group in the Registers combines the two classes and has five Elements (slightly renamed from the above and with altered optional/mandatory status) – note that “IndexSID” and “SampleIndex” are distinct Elements, as are “BodySID” and “EssenceStream”. Clearly AAF and MXF files must only encode the three Elements that are appropriate for the file format.

Assume that we want to produce a Reg-XML instance document that does not use the Part 2 AAF Baseline (because this Baseline is AAF-centric). Then when a Reg-XML instance XML is created from an MXF file, for each “Essence Container Data” Set encountered the MXF reader must:

  1. Create an “EssenceData” instance in the Reg-XML instance XML and populate it with the properties found in the MXF file
  2. Optionally find the Streams of data identified (in Containers) with the “IndexSID” and “BodySID” specified and extract each Stream to a separate file. Augment the “EssenceData” instance in the Reg-XML instance XML with (as required):
    • “SampleIndex” with a link (e.g. xlink:href) to the separate file into which the bytes of the index stream identified by “IndexSID” have been extracted.
    • “EssenceStream” with a link (e.g. xlink:href) to the separate file into which the bytes of the essence stream identified by “BodySID” have been extracted.

Note:

  • this requires an MXF reader to have special built-in knowledge that these Elements in instances of this Group have to be treated in this special way – nothing in the Registers entries will communicate that fact (the Elements in question do not, for example, have a special Type).
  • Stream files in a Reg-XML file group contain the entire container from the MXF file including the KLV coding. A/V are not de-interleaved. Index Tables are not decoded.

Other uses of “Stream”

The current assumption (not fully investigated) is that no other properties in MXF are Stream IDs and probably all those properties that claim to be of Type “Stream” are actually of Type “DataValue” when used in MXF.

For example, “ChunkData” (ST 382) claims to be of Type “Stream”. However, the description in ST 382 makes it clear that it is actually of Type “DataValue” in practice. The defining standard (ST 382) as well as the corresponding Elements Register entry would need to be updated (if possible).

The situation is similar with “PeakEnvelopeData” although this is also defined in AAF with Type “Stream”.